When making calls between entities, a user may find it convenient, or even necessary, to mute the microphone of the user's communication device. In other words, a user may initiate a mute function associated with a communication device to prevent the microphone conveying sound to one or more other users participating in the call. Among other things, muting the microphone can provide a user with a certain level of privacy by preventing one or more other users from hearing what the user is doing or saying while the mute function is active. Some of the benefits associated with muting the communication device may include the ability for a user to hold a private conversation, cough, sneeze, perform other tasks, use another communication device, type on a keyboard, prevent distraction in a noisy environment, and the like.
Although it is common practice to mute a telephone while on a call, it is even more common when a user is on a conference call. It is a frequent occurrence, however, that one or more of the users participating in a conference call may forget to deactivate, or unmute, the mute function of their device. In this instance, a user may begin to speak to other conference participants without realizing that the mute function is still active, and as a result, the user cannot be heard by the other participants. Complicating the issue, the user may not be aware that the mute is still active until no other participant in the call acknowledges or responds to their dialogue. As can be appreciated, this scenario does not result in a desirable user experience. Not only is it frustrating for a user to speak and later realize that nothing spoken was heard, but it can also be embarrassing for the user and others in the call. Moreover, any delay caused between what the user thought was heard during an active mute and what the user must repeat when the mute is deactivated wastes the time of the teleconference participants and can disrupt the flow of a discussion.
Some have attempted to solve the problem of notifying users that a mute function has been engaged by providing an alert to a user. The alert may be provided in the form of a periodic tone, or “beep,” that is output to the speaker of a user's telephone device. In some cases, the alert may be provided in the form of a flashing light, or text, to try and alert a user when the mute function of a telephone device is activated. In any event, it is expected that a user should hear, or see, the alert and respond by deactivating the mute function before attempting to participate in a conversation.
Unfortunately, these alerts do not adequately solve the problem associated with mute notification in communications across a network. For example, the periodic tone can be distracting to a user and may even mask the call content with each tone output. In other words, as the periodic tone is output to the user's device, any coincident audio output by the one or more other participants in the call may be cutoff, misunderstood, or result in unintelligible sounds. Furthermore, if the periodic tone is output to sound at longer intervals, a user may speak during the tone intervals only to realize later (e.g., at a subsequent tone output) that the mute function was active. The flashing light, or text, alert may be distracting in some implementations and unnoticeable in other implementations. For example, a bright light, or one having a quick illumination pulse, may be found annoying by a user. In contrast, if the light alert is dim, or displays at long intervals, the alert may go unnoticed. Furthermore, flashing lights suffer from context in their application. For instance, without knowing that the flashing light indicates that mute function of the device is active a user may associate the flashing light with some other meaning (e.g., a call is on hold, incoming call on another line, a message has been left on the device, etc.).